年底又顺利升职了！ 分享一些经验和看法！

职场新人入职两年半的省思与心得

作者@chunlun2发布在一亩三分地

欢迎大家点击左下角“阅读原文”到原帖与作者交流讨论哦！

又过了一年，今年虽然没有去年顺利，还是在年底的时候幸运的再次拿到升职的许可。

想著应该是要回头看看这一年的成长，看能不能总结出一些经心得能与大家分享。

板上厉害的人非常多，如同去年所撰写的一篇心得文章：职场新人入职快一年的升职省思与心得，一样的disclaimer：

这更多是我自身经验的总结，或许不适用在所有人身上，是一些我自己犯过的错、踩过的坑、亦或是我认为我能顺利升职的原因分享。

Define the scope

这点是我之前一直忽略的，也是因爲没有适时的define好scope，在很多状况下都吃了不少亏。Define scope可以用在多个地方：以写design doc为例，当你在设计一个新design或是在对一个feature写design doc时，如果没有事前想好这分doc的scope，那你可能会花大多时间在不需要的的地方，或是在做doc review时面对排山倒海而来的问题不知所措。

在做doc review时，同事、主管或是其他参与review的其他人都很有可能会问出很多你本来没想好的问题，如果未能在present你的doc之前想好你这份doc的scope，那你可能会对于很多问题回以沉默或是不清楚。大多时候，你比其他人都清楚这个feature/design是什麽，大概的成果样子是什么，或是你了解他的最终目的是什麽。设定好scope可以帮助你减少收到一些不相干的feedback亦或是在对于不相干的问题时，给予一个明确的答案：“你的问题不在本次我present的design doc的范畴”。

很多时候我们都知道对于不相干的问题对于你的doc present有著严重的影响，有时会让讨论方向偏移，导至为了要回答其中一个问题而没有机会让你著重说明你想说的部分，防止讨论主体的失焦是define scope的一个重要帮助，这能让你的present更流畅，事前自己想清楚了scope是什麽时，更能帮助你focus在对的症结点上。

Define Scope可以应用在多个场景上，不只是design doc。Code review也是一个常见的场景，很容易在给同事code review时收到类似景象：当能你调用到了某个函式，但却收到希望你能改进那个函式的评论，或是你改了A其他人希望妳能”顺便“帮忙改B，面对这种情况，可能导致那个PR越来越大，越容易出错越难完成，容易不小心投入过多却不能真实的反映在你的项目完成度上，这很多时候是一开始自己对于”这个” PR的scope不够清楚而导致。(当然如果你很愿意又有时间，don’t leave bad code behind是一个好的mindset！)

最后define好scope的重要性更体现在success metrics上，如果你尚不能define好一个task的scope，那怎么能正确的量化你的success？也正是你已经事前设定好了scope，在做回顾或这量化时都会变得无比轻松与明确，这能有助于你展现自己完成任务的准确度与达成率，让你的努力更鲜明地展现出来。

Take responsibility

随著年资的增加这项的佔比应该会愈来越大、越来越重要。也是我认为区别初级与资深工程师的重要指标。当一个task交到你手上时，不管task的大小，如果能马上拥有task的responsibility，我想应该会对你受益良多。具体take responsibility是什麽呢，这个一时半会儿说不太清，如果你能回答以下问题或是没有其中经验那你应该是已经养成了这个习惯：

为什麽我们要做这个task呢？这个task的影响是什麽？产生了什麽impact? 如果让你建立它的下一步或是following task那会是什麽呢？遇到了完成这个task后产生的bug，积极的处理，而不是说 大家code review时都同意了或是说这个方法我doc review时已经signoff了 (所以不会是我的问题)。回答问题时从不说 “是某某A让我这样做的”、“当时大家都同意了”

我想大家(包括主管)应该不是讨厌容易写出bug或是造成bug的工程师(太离谱不在讨论范围 lol)但大家可能不是那麽喜欢推脱责任、不能倚靠的工程师同事。让take responsibility 成为习惯能让你从底层了解与学习，更能让你树立靠谱的形象，未来对于拿到好的、大的、有vision的任务会有一定的帮助。

Quantifying

“量化、数据化”这些词我也是到了很后来才觉得重要，因为这是最直接明白的形式以下例子你应该就能明白。

当你在给别人PR comment时，尽量不要写“我觉得这样做不好”你应该写“我觉得这样不好因为XXX 然后这是我的POC(proof of concept)，其显示这样会有问题、改成YYY会更好”。

人是直觉的动物但对于工作我们需要做到明确、没有模糊空间，单单地表明这样写不好根本上就像没有这个comment一样，对方无法理解哪裡不好是一个最大的问题。若只写 “我觉得这样不好，请改这样”也是不太合适的，大家都是工程师怎麽你的就是对的？最好说服的方法是：点出需要修改的地方，并给出真实的数据作证你的论点，它可以是一个显而易见的后果，如果没有如此显而易见，给出自己尝试过后的POC会是一个更好的方式。

当你在给主管反馈说自己会议时间太长，会议时间太多的时候，单单前面两句话是不够的，“多”只是一个形容词，每个人的定义不同，主管也很难著手帮助你，更好的方法是 说出自己觉得会议太长会议太多的感受 并给出具体的一週会议时间 以及你都参与了那些会议，这些资料才能真正的使主管了解进而帮助你的问题。

以上都是如何使用“量化、数据化”的实际例子。“量化、数据化”的重要性体现在能更好的与同事们、与主管沟通，能让你的提议更能被接受，减少中间来回回解释的时间，也更能体现你的努力与贡献，不埋头苦做而忘了用其他人容易吸收的方式传递你的贡献！

以上是我个人的小心得，作为自身记录的同时，希望能帮助到其他人。

大家都爱看

新闻来源一亩三分地论坛，版权归原作者所有
本文禁止任何形式的转载，请与一亩三分地联系